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REMARKS 



As a result of this Amendment, claims 1-28 remain pending in this case. Claim 1, 3, 6, 
1 1 and 21 are amended. Reconsideration of the application is respectfully requested in light of 
the above amendments and the following remarks. 

This amendment is responsive to the Office Action mailed March 12, 2003. In that 
Office Action, claims 1-28 were examined and rejected. Claims 1, 3 and 6 were rejected under 
35 U.S.C. 1 12 as containing problems in antecedent basis. Claims 1-9, 11-19 and 21-23 were 
rejected under 35 U.S.C. 102(e) as being anticipated by D'Errico et al., (U.S. Pat. No. 6,457,139, 
hereinafter "D'Errico"). Claims 24-27 were rejected under 35 U.S.C. 103(a) as being obvious in 
view of D'Errico. Claims 10, 20, and 28 were rejected under 35 U.S.C. 103(a) as being obvious 
over D'Errico in view of Blumenau (U.S. Pat. No. 6,240,51 1 hereinafter "Blumenau"). 

Claim Amendments 

Claims 1, 3 and 6 were rejected under 35 U.S.C. 1 12 as containing problems in 
antecedent basis. These claims are amended to correct this problem and withdrawal of the 
rejected is respectfully requested. 

Claims 1 1 and 21 are amended to clarify that the application programming interface as 
claimed is presented by the volume provider and that the volume provider is configuring the 
storage volume. Support for this amendment can be found, among other places, on Page 3 at line 
20, and Page 13 at lines 10-15. 



D'Errico describes a storage system 3 analogous to the Applicants' storage devices 106. 
D'Errico discloses a host computer 1 having an application layer 21 and a logical volume 
management layer 23 and a storage system 3 having a storage system mapping layer 25 as 
described below: 

The layers include an application layer 21 that resides on the host computer 1 and 
references data objects (e.g., files) used by the application. In addition, the host computer 
1 also includes a file system and/or logical volume manager layer 23 that maps each data 
object specified by the application layer 21 to a particular logical volume, that the host 
computer 1 perceives to correspond to an actual physical storage device, wherein the data 
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object is stored. Thus, if the computer system included a storage system without any 
intelligence, the logical volumes specified by the file system/LVM layer 23 would 
designate a particular physical device and a particular storage location thereon wherein 
the data object would be stored. Finally, the computer system further includes a storage 
system mapping layer 25 that resides on the storage system, and that maps from the 
logical volume provided from layer 23 to an actual physical location, including at least 
one of the disk drives 5a-5b and the physical location thereon, wherein the logical 
volume is stored. D*Errico Col. 2, lines 8-24. 

Note that D'Errico*s description indicates that the storage volume management is performed by 

the LVM layer 23 which is part of the host computer 1. 

D^Errico presents embodiments of a storage system 3, including a storage system 3 

having an application programming interface (API). However, D'Errico clearly states that the 

API is for the storage system 3 so that the host computer 1 may make requests to and receive 

information from the storage system 3. 

For example, an application programming interface can be defined between the 
host computer 1 and the storage system 3 that enables the host computer 1 to provide a 
request to the storage system 3 for information relating to the physical mapping for a 
particular logical volume, as well as information relating to certain characteristics of the 
physical device(s) on which the logical volume is stored. This information can be used by 
various portions of the host computer 1 (e.g., the file system/logical volume mapping 
layer 23 of FIG. 2) to configure data amongst the logical volumes defined by the host 
computer 1 in a manner that will maximize system performance once those logical 
volumes are mapped to the physical layer within the storage system 3. Thus, using the 
information provided by the storage system 3, the host computer 1 can make more 
intelligent mapping decisions that will improve the overall performance of the computer 
system. D'Errico, Col. 15, lines 13-29, emphasis added. 

Generally, D'Errico's is directed to providing a smart storage system that is transparent to 
the host computer and can address problems such as hot spots that are created by poor 
configuration of storage volumes by the LVM layer, while retaining the LVM's configuration of 
the storage volumes. It should be stressed that in D'Errico, the operation of the storage system 3 
is transparent to the host computer 1, and thus the LVM layer 23. See, e.g., D'Errico Col. 6 at 
lines 60-66, Col. 12 at Hnes 3-5, and Col. 12 at lines 52-59. As far as the LVM layer knows, the 
storage system does not change the logical volume mapping performed by the LVM layer. This 
is true even when the storage system is identifying and responding to hot spots and accessibility 
issues by changing the physical mapping of the logical volumes to create metavolumes and 
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hypervolumes unknown to the host computer. Ahhough the storage system can provide 
information to the host computer if requested, D'Errico is not concerned with exactly what the 
host computer may, or may not, do with this information. 

Rejection Under S102(e) over D'Errico 

Under 35 U.S.C. § 102, a reference must show or describe each and every element 
claimed in order to anticipate the claims. Verdegaal Bros. v. Union Oil Co. of California 814 
F.2d 628 (Fed. Cir. 1987) ("A claim is anticipated only if each and every element as set forth in 
the claim is found, either expressly or inherently described, in a single prior art reference.")- The 
Applicants respectfully submit that D'Errico does not anticipate the Applicants' claimed 
invention because it does not show or describe each and every element. 

The Examiner rejects AppHcants' independent claims 1, 11,21 and 23, stating that 
D'Errico discloses a volume provider (citing D'Errico*s LVM Layer 23) and API (Col. 15, Hnes 
3-29). Applicants agree that D'Errico does disclose a storage system 3 with an API and a 
"logical volume manager [LVM] layer 23 that maps each data object specified by the application 
layer 21 to a particular logical volume,..." D'Errico, Col. 2, lines 9-12. However, as discussed in 
greater detail below D'Errico certainly does not disclose a volume provider with an API or an 
API as claimed. 

1 . D'Errico does not in any way teach or suggest a volume provider that presents an API 
D'Errico's sole mention of an API, as discussed above, is clearly described as provided 
solely by the storage system 3 to the host computer. D'Errico contains no other references to an 
interface at all. The storage system 3 is clearly defined as separate and distinct from the host 
computer 1 and, thus, the LVM layer 23. D'Errico's FIG. 2 even shows a barrier between the 
LVM Layer 23 and storage system mapping layer 25 to illustrate that the host computer and 
storage system are entirely separate. Furthermore, D'Errico is silent to details of the internal 
operation of the host computer 1 beyond general descriptions of its functions and requests that 
are necessary to provide the environment for the storage system 3. Therefore, D'Errico does not 
in any way teach or suggest a volume provider that presents an API as claimed in claim 1,11 and 
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21 . To the extent that claims 1 1 and 21 were ambiguously worded, they have been amended to 
clearly claim that the API is presented by the volume provider. 

2, D'Errico does not in any way teach or suggest an API for receiving behavioral 
attributes of the storage volume 

D'Errico does not disclose, teach or suggest an API that characterizes "behavioral 
attributes" of a storage volume as claimed in claims 1,11,21, and 23. D'Errico clearly states 
that the storage system API is limited to characterizing "information relating to the physical 
mapping for a particular logical volume, as well as information relating to certain characteristics 
of the physical device(s) on which the logical volume is stored." D'Errico, Col. 15, lines 17-20. 
D'Errico's storage system API provides physical information because the storage system makes 
decisions related to the physical mapping of the logical volumes previously defined by the LVM 
layer 23. D'Errico's storage system API need not provide behavioral attributes to the host 
computer, as the host computer already knows the behavioral attributes because it dictates them 
to the LVM layer so that the volumes defined by the LVM layer will have the correct 
characteristics. D'Errico's storage system API is only for reporting physical mapping 
information back to the host computer, not for receiving information. D'Errico simply does not 
disclose an API for receiving behavioral attributes of one or more storage volumes. 

For the reasons given above, D'Errico's disclosure of a storage system with an API for 
providing physical mapping information to a host computer does not disclose, teach or suggest 
all the elements as claimed in the independent claims 1,11,21, and 23. Therefore, the 
Applicants respectfully request that the Examiner withdraw his rejection and find the pending 
claims in a condition for allowance. 

3. D'Errico does not in any way teach or suggest configuring storage volumes as a 
function of the storage access information received by an API 

While D'Errico discusses a storage system 3 that physically maps predefined storage 
volumes based on various factors, D'Errico does not teach or suggest configuring or changing the 
storage volumes defined by the volume provider. D'Errico's storage system is completely 
transparent to the volume provider and, as far as the volume provider is concerned, has no effect 
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on the volumes mapped by the volume provider. The closest D*Errico comes to this is stating 
that information provided from the storage system to the host computer may be used to improve 
the initial mapping of volumes by the host computer. D'Errico, Col. 15, lines 13-29. Hov^ the 
host computer achieves this is beyond the scope of D'Errico, as D'Errico is only concerned with 
operation of the storage system. D'Errico simply does not teach configuring storage volumes as 
a function of the storage access information received by an API. 

In sum, D'Errico does not teach each and every element of the independent claims and, 
therefore, does not anticipate the claims under 35 U.S.C. §102. Thus, the Applicants respectfully 
request that the Examiner w^ithdraw this rejection and find the independent claims 1,11,21 and 
23 and all the claims dependent therefrom to be in a condition for allovv^ance. 

Rejection Under $lQ3(a) over D'Errico 

The Examiner rejected claims 24-27 as obvious over D'Errico. For the reasons stated 
above, the Applicants believe that the Examiner has mischaracterized the API discussed by 
D'Errico. D'Errico's API provides physical mapping information to the host computer, and does 
not receive information concerning the storage volumes. Therefore, Applicants submit that all of 
the elements are not disclosed by D'Errico. The Examiner has not supplied a motive or 
suggestion in D'Errico for providing the missing elements. Nor can the Examiner find such a 
motive as D'Errico is not concerned with the operation of the volume provider. Therefore, 
Applicants respectfully request that the examiner withdraw this rejection and find these claims in 
a condition for allowance. 

Rejection Under $103(a) over D'Errico in view of Blumenau 

The Examiner rejected claims 10, 20 and 28 as obvious over D'Errico in view of 
Blumenau. The Examiner provides Blumenau as an example of implementing a storage system 
in an object-oriented language. The Applicants would like to point out the claims are directed to 
an API that conforms to a Component Object Model (COM) interface. An API that conforms to 
a Component Object Model (COM) interface can be provided by programs that are not written in 
an object-oriented language. For example, a programmer can write programs in C (not an 
object-oriented programming language) that implement COM conforming interfaces. Similarly, 



10 



S/N 09/450,364 



PATENT 
Confirmation No. 7529 



implementing a system via an object-oriented language does not require the use of a COM 
interface. 

For this reason, the AppUcants believe that Blumenau does not anticipate a COM 
conforming interface. Therefore, the Examiner has not shown all of the elements as required and 
the Applicants respectfully request that the Examiner withdraw the rejection in view of 
Blumenau. 

Conclusion 

In light of the foregoing remarks, it is believed that the application is in condition for 
allowance and thus prompt allowance is respectfully solicited. Should the Examiner have any 
remaining questions, he is encouraged to contact the undersigned attorney at the telephone 
number below to expeditiously resolve such concerns. Please charge any additional fees or 
credit any overpayment to Deposit Account No. 13-2725. 



Respectfully submitted, 
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George C. Lewis, Reg. No. 53,214 
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